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1.0 Scope 

The purpose of this report is to assess Vehicle Health Management(VHM) technologies for 
implementation as a demonstration. Extensive studies have been performed to determine 
technologies which could be implemented on the Atlas and Centaur vehicles as part of a bridging 
program. This paper discusses areas today where VHM can be implemented for benefits in 
reliability, performance, and cost reduction. VHM Options are identified and one demonstration is 
recommended for execution. 

2.0 Need for VHM 

All launch vehicles, including manned and expendable, have required extensive testing to insure 
system integrity, reliability, and operability. Testing was performed when the vehicle was on the 
pad weeks and days before launch. Vehicle sensors, Ground Support Equipment (GSE), and 
manpower were required to perform the vehicle testing. 

The existing vehicles require large standing armies to process each vehicle for launch. Reducing 
costs for the Atlas vehicles is a goal to improve the competitive standing in the commercial 
markets. Efforts were first started in avionics and post flight data analysis but have spread to all 
vehicle systems. The new technologies being developed are known as Vehicle Health 
Management. However, VHM is not a new system but rather a new way of doing business. 

A major goal of new vehicles, such as the Spacelifter or National Launch System(NLS) family, is 
to reduce operations a factor of 5 to 10 over existing vehicles. Improving on present vehicles is a 
driving force in the creation of new vehicles. Testing of the new vehicles using existing methods 
would not meet cost objectives. Thus, the new programs require better testing in order to achieve 
their goals. A solution is found in the VHM designs to upgrade existing vehicles. Systems proven 
on today’s vehicles can be implemented on tomorrow's. The advantage the new programs have is 
that benefits can be designed in rather than retrofitted. On some systems retrofitting is too 
expensive and benefits will only occur in a new clean sheet vehicle design. 

The need for VHM technologies is widely recognized by the USAF, NASA, and industry 
members. On the recent NLS program VHM was considered a key element to achieve program 
goals. NASA considers VHM the highest priority of 21 key technology requirements of current 
and future OSF missions. NASA Code M and Code R created the Strategic Avionics Technology 
Working Group(SATWG) composed of government and industry members in 1990. One 
SATWG panel is focused on planning and developing VHM with NASA/industry cooperation. 
The SATWG effort has already made progress in determining needs, requirements, goals, and 
objectives for VHM at NASA. Work is currently underway on VHM projects within groups at 
NASA's Johnson Space Center (JSC), Marshall Space Flight Center (MSFC), and Lewis 
Research Center(LeRC). 

The progress bridging program demonstrations can accomplish for VHM is shown in Figure 1. 
The program begins with a demonstration on the Atlas and Centaur vehicles. In the current 
propulsion system on the Atlas HAS no hold down health monitoring or automated pre-launch 
checkout exists. If that demonstration were carried out the potential benefits such as improving 
reliability and cost savings would be proven. The designs and processes created in the program 
could then be incorporated into a new vehicle design such as the HLLV or Spacelifter. The 
demonstration begins a progression toward the expected need for on-board propulsion system 
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verification needed for a Lunar Transfer Vehicle (LTV), part of the Space Exploration Initiative 
(SEI). Although there are additional steps required, the bridging program builds confidence in the 
new technology for continued development. 

HLLV 




Engine Hold-Down & 
Automatic Pre-Launch C/O 

• Reliability Improvement 

• Cost Savings 

• Platform Demonstration 


Figure 1. 


Bridging VHM Technology Evolution 


A VHM system is designed to monitor the health status of vehicle subsystems in the most cost 
efficient manner. VHM automates tasks performed manually. In addition, VHM can be described 
as the major component in an Integrated Health Management (1HM) system. VHM allows IHM to 
detect and manage any component failures in a redundant system. The components include but are 
not limited to valves, pumps, sensors, software, and ground systems. VHM is not specifically an 
avionics system, but rather uses Avionics to accomplish its tasks. For example, a subsystem 
would communicate using an data bus, but the subsystem could be located in the propulsion 
system. An entire test would begin with a command being sent to a system, the system’s health 
status would be determined, and the status sent back to the test conductor. The system would be 
automated to the maximum amount possible to reduce labor costs. 


The efforts underway for the Atlas, Centaur, and new vehicles focus on developing promising 
technologies for different subsystems and identifying requirements. Specifically, efforts on Atlas 
and Centaur have occurred in the avionics, pneumatics, propulsion, and operations areas. Specific 
plans have been created in order to develop and demonstrate the applications on real systems. The 
technology which we believe is the highest priority is described with a plan for implementation. 
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3.0 VHM Benefits 


The benefits of VHM development are reduction of costs, reliability improvements, and 
performance improvements. The goal of the VHM demonstrations is to prove the VHM benefits 
using actual hardware. Once the technology is proven then insertion into existing or new programs 
can follow. This demonstration can also lead to other technologies with further savings. VHM 
will be a requirement for many missions which will have a long duration such as SEI. The 
systems for these vehicles requires the additional performance that only VHM can provide. 

The reduction of costs for VHM will occur from automating vehicle checkout functions for vehicle 
operations. Automation reduces or eliminates the impacts of launch delays, aborts, and recycling. 
Additionally, fewer people are required to perform tests. An example for achieving operations 
savings is replacing die hydraulic Thrust Vector Control (TVC) system with an Electromechanical 
Actuator (EMA) on the Shuttle Solid Rocked Boosters (SSRB). This would reduce TVC 
operations from 16 shifts down to 3 with fewer technicians required at each step. The EMA design 
takes maximum advantage of automated testing systems. With VHM vehicle checkouts will take a 
shorter time to execute thereby decreasing launch processing, increasing launch availability, and 
reducing launch cycling time. 

Reliability improvements will occur due to enhanced system designs. Redundancy is one method 
used to increase system reliability, but redundancy requires extra system testing. VHM provides 
for testing an entire system easily. VHM allows for testing and re-configuring to isolate faults in 
redundant systems. Another example of increasing reliability is holding down the Atlas booster to 
test proper propulsion system operation. If any system monitors detect anomalies the engines can 
be shut-down to prevent loss of mission. This hold down monitoring was estimated to raise ascent 
reliability 2 - 3% for the NLS program. 

With increased testing done by VHM systems performance margins can be improved. Present 
margins can be increased from analysis of additional data. VHM allows for storage and analysis of 
vehicle parameters. The data can be used to create a history of system operation to determine sub 
optimal operation. In addition, the data then can be used to improve understanding and 
capabilities of the vehicle. 

4.0 VHM Demonstration Plans 

Although VHM must be designed in over the entire vehicle, each system has some VHM 
component within. Potential VHM improvements are possible for every major vehicle subsystem. 
However, in order to minimize expected demonstration cost and because of the underdeveloped 
status of VHM the suggested demonstrations are focused at the subsystem level. The subsystems 
considered for VHM demonstrations include ground equipment, data analysis, fluids, thrust vector 
control, avionics, and propulsion. 

Information on the majority of the plans is not included with this report due to the proprietary 
nature of the demonstrations and plans . However, this report will described the detailed plan for 
the demonstration considered to be the highest priority. 

5.0 Highest Priority Demonstration Plan 

After considering available hardware, schedules, costs, risks, and benefits the avionics 
demonstration is the plan with the highest priority. The avionics system demonstration is known 
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as Avionics Built-In-Test (BIT). In this section the methodology of selecting the demonstration is 
explained, a detailed plan is described, and the benefits versus costs are listed. In addition, 
hardware, lab facilities, schedule, and costs are described. The demonstration plan is shown in 
Quad Chart format in Figure 2. 


Task Objectives/Benefits 

Demonstratlon/Brldglng Approach 

Objectives): 

Develop & demonstrate an IVHM architecture for launch 
vehicles to include the avionics system and its interfaces 
with other vehicle subsystems 

Applicable Vehicles: 

ELV, ETO-LV, Upper Stages, SEI 

Task(s): 

1 . Develop integrated VHM architecture requirements 

2. Generate avionics architecture using NLS ADP 
Technology 

3. Test & demonstrate avionic capabilities 

4. Integrate avionics with other lab facilities 

5. Test & demonstrate integrated vehicle systems 

Benefits: 






• Enhances system reliability & reduces checkout time, 
manpower & cost 

• Improved IVHM efficiency by addressing subsystem 
interface issues 

• Reduce risk when applied to flight program 

Available Facilities: 

MSFC: MAST. TTB. Actuator Lab. Flight Sim Lab 

Technology Description 

Schedule/Cost 

NASA Technology Readiness Level: 


TASK 

FY94 

FY95 

FY96 
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Specifications: 

• Fault tolerant avionics architecture including hardware & 

software designs 

• Health management interface issues between subsystems 

addressed/demonstrated 

• Demonstrations will use existing test facilities & simulations 
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• MAST Lab will provide central facility for test/demo of total 
integrated system 
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Resources 

200K 

400 K 

700K 
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Figure 2 . Avionics BIT Quad Chart 


5 . 1 Methodology of Plan Selection 

The Avionics BIT demonstration was decided over the other demonstrations on the basis of 
reduced risk, costs, potential benefits, and available facilities. Each option was given a weight in 
the four categories. The resultant matrix is shown in Figure 3. The four discriminators were to 
generate distinctions between the options for purposes of evaluation. 

The avionics program has less risk than the other projects because this task modifies and 
demonstrates developed avionics hardware. The estimated cost of the project is among the lowest . 
The benefits from this project are in line with the majority of the other demonstrations. Finally, the 
demonstrations is flexible with all available facilities. The demonstration hardware could 
potentially be relocated to many sites around the country. The BIT program is also important in 
that it creates the vehicle infrastructure for many of the other plans. 

The fluids and GSE systems require designing and building new unique hardware. Costs are 
higher for these other projects due to the new hardware. The propulsion plan has tremendous 
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benefits but the costs at this time seem excessive. The second alternate is developing an EMA 
Health Management system, but similar work is already underway within NASA. 
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Figure 3. VHM Demonstration Analysis 


5.1.1 Benefits of Avionics VHM 


The checkout of on-board avionics systems is time consuming and reliability improvements could 
be gained by utilizing BIT technologies. Operational costs can be reduced and checkout benefits 
can extend to other vehicle systems(propulsion, fluids & EMA) using VHM BIT components. 

Current launch vehicles incorporate limited automated test capability and take an approach to 
checkout that is time consuming and labor intensive. Factory checkout is accomplished today 
using manual methods to verify continuity and function. On the pad, many support technicians are 
needed to monitor the system and make go/no-go decisions. Ground test equipment is used 
intrusively during the checkout operations. Intrusive testing physically disturbs vehicle signal lines 
and components and thereby reduces the overall reliability of die test operations. When problems 
are identified, usually through tedious examination of test or telemetry data, fixes tend to be 
expensive and time consuming. Hardware repairs generally require replacement of an entire 
electronics assembly, a process that often requires multiple technicians working in tight quarters. 
Since numerous connectors must be removed and replaced to replace the assembly, the integrity of 
the complete system must be reverified after the repair. 

Factory closeout and pad checkout of avionics systems could be improved by utilizing avionics 
technologies such as multi-level Built-In-Test (BIT) functions and independent Test and 
Maintenance buses. These technologies would be demonstrated as part of a proposed Avionics 
Built-In-Test Demonstration. 

In addition to performing avionics checkout, an avionics system can be extensively used to 
automate the operations of other major subsystems, such as propulsion and fluids. Additionally, 
avionics BIT technologies can enable operations that cannot be performed manually, such as for 
long duration missions, or highly autonomous systems. 

In order to automate the checkout of avionics and non-avionics subsystems, the avionics 
architecture must contain the attributes to enable this automation. Present day avionics systems do 
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not have the components required to support highly automated checkout of vehicle subsystems. 
Only a few BIT capabilities currently are used, and the test results are not distributed system- wide 
for fault analysis or configuration management. 

In order to fully utilize avionics for automated operations, the avionics architecture must have the 
required attributes designed into the system. Among the technical requirements needed to perform 
automated operations are improved data processing, storage and distribution capabilities, smart 
instrumentation and effectors, multi-level Built-In-Test functions, and independent Test and 
Maintenance buses. 


An avionics Built-In-Test demonstration would show the benefits that an automated BIT capability 
has over conventional item-by-item check-out and replace/remove/re- verification procedures. 

Demonstration hardware will consist of a selection of Joint Integrated Avionics Working Group 
(JIAWG) Common Modules (see figure 4). These common modules are the result of the Pave 
P illar Avionics Architecture development effort at the USAF Wright Research and Development 
Center. This common module architecture has been baselined for the F-22, AH-64, and various 
military aircraft upgrades. 


• POSITIVE LOCK-DOWN 
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• MIL-STD-1389D FORMAT 
(DOUBLE-SIDED) 


• PI-BUS BACKPLANE 
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Figure 4. JIAWG Common Modules 

The JIAWG common modules contain extensive BIT capabilities that enable subsystem level 
testing and fault isolation down to a line replaceable module (LRM). At system power-up, BIT 
functions detect failures in such module resources as processor chip sets, backplane bus chip sets, 
maintenance & controller chip sets, memory and supporting logic. In background mode, BIT is 
constantly monitoring module health during operation. The common module BIT architecture 
maintains module health status in on-board error logs and status registers. These logs and registers 
can be accessed via a calling program for analysis. If the avionics architecture has an appropriate 
databus system, the BIT information can be available across the system and to ground systems. 
When applied to launch vehicle avionics, the JIAWG Common Module BIT capabilities greatly 
reduces fault isolation and replacement time in the factory and on the pad. 

The Avionics BIT Demonstration would have direct applicability to next generation Health 
Management Systems. In particular Space Station Freedom, Spacelifter, CTV and SEI would 
benefit. 
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5 . 2 Detailed Plan Description 

The Avionics Built-In-Test Demonstration will show the operational advantages of using BIT 
technologies to automate the system-level checkout of avionics. The demonstration goal is to show 
how an avionics can aid operations by using Built-In-Test technologies to automate checkout 
operations and monitor system health during operation. It will be shown how avionics common 
module BIT technologies are used to determine component, module, subsystem, and system level 
health. 

The Marshall Avionics Simulation Testbed (MAST) Lab at NASA’s Marshall Space Flight Center 
is the proposed site for the first demonstration. The goal in the first year will be to demonstrate 
BIT capabilities of a single-string avionics system. The program will begin by generating 
requirements for the architecture. Next, the architecture will be configured into a single-string 
system. Demonstrations the following years will incorporate fault tolerant system designs. 
Additional systems which interface to the avionics system will be integrated. Additional hardware 
to be potentially integrated include equipment from the JSC VHM NRA and EMA hardware at 
MSFC labs. 

First year demonstration hardware will consist of a selection of JIAWG common modules, a 
common module chassis with a PI-bus/TM-bus backplane, a Micro VAX software development 
processor and controller, a 6U chassis with VMEbus backplane, a simulation computer, and a host 
of coding and display terminals. The configuration will be linked together by a combination of a 
local area network, backplane system buses, and a main system bus. Flight software for the 
common module hardware will be in the Ada language. Software on the simulation computer will 
be written in the C language using a real-time Unix operating system. The host system for display 
of the demonstration data is to be determined. Potential display systems could be a PC system, a 
Silicon Graphics system (SGI), or a Sun workstation. 

The following subsections describe the built-in-test and data networking technologies used in the 
demonstration as well as the hardware and software requirements. 

5.2.1 Built-In-Test Capabilities 

The JIAWG common module test and monitor capabilities minimize intrusive testing to provide 
higher hardware reliability and reduce the risk of operator induced errors. This is accomplished 
through the use of several levels of self-diagnosis and check out, starting with the capabilities that 
are built into the common modules. 

Extensive BIT is in place today in JIAWG common modules: 

Power-up BIT detects failures of module resources such as: 

- Processor Chip Set 

- Resource Controller / Backplane Bus Chip Set 
— System Data Bus Chip Set 

- Maintenance Controller Chip Set 

- Local/Bulk Memory 
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- Supporting Module Logic 

Performance Monitoring BIT operates in background mode and consists of three different 
packages. 


- Applications Self-test Software 

- Initiated Self-test Software 

- Maintenance Controller Firmware 

Off-Line BIT is designed to do complete testing of a module without interfering with system 
operation. 

All faults, whether permanent of intermittent, are logged by the maintenance controller in error log 
memory. 

Different levels of testing are accomplished in each BIT mode. 

Level 1: Tests all available module capabilities without stimulating any external 

output line or requiring any external stimuli. 

Level 2: Verifies the intermodule capabilities and busses which require intermodule 

coordination (e.g. TM-bus) 

Level 3: Verifies intersubsystem capabilities and busses requiring intersubsystem 

coordination. 

The common module BIT program architecture covers level 1 and 2 testing. The overall system 
performs level 3 testing to verify intersubsystem capabilities, buses and network verification. It 
also performs non-avionics checkout of other subsystems such as electromechanical actuators, 
fluids and propulsion systems and various pieces of instrumentation on the vehicle. 

5.2.2 Test and Maintenance Buses 

Currently, system testing is performed using manual methods to check continuity and 
functionality. Often this is a labor intensive, time consuming process. Test data is usually 
transferred over existing system databuses. A failure of these buses would result in the subsequent 
failure of system testing. This problem is alleviated if there is independence between test buses 
and standard system buses. 

Test and maintenance buses provide an independent path for the distribution of health, maintenance 
and built-in-test information. They also provide a clean interface for external test equipment and 
test data retrieval. A test bus structure ensures that test information does not interfere with normal 
system operations and enables test procedures to be performed in a variety of modes (powered- 
down, degraded, full-up, etc.) In addition to system checkout, test buses can exchange health 
information during normal system operation independently from standard system operations. 

JIAWG Common Modules make use of a Multi-level Test and Maintenance bus (TM-bus) 
structure. This structure includes system-level TM-buses, subsystem (backplane) TM-buses, and 
chip and module level TM-buses. This structure enables verification of a system on multiple levels 
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and permits isolation of faults to the smallest possible component. For a modular architecture, this 
permits isolation a line replaceable module (LRM). The system-level TM-bus (STM) is typically a 
serial, master/slave bus configuration. Control of the STM bus resides in the primary avionics 
computer subsystem. JI AW G Common Modules contain module-level TM buses. These buses 
exchange test and maintenance data among the modules in a given subsystem. 

5.2.3 Demonstration Hardware 

The following list of equipment will be used in the demonstration as discussed within this 
document. 

JIAWG Common Module Chassis - With a complement of JIAWG common modules, this 
chassis is representative of a flight control computer. The chassis contains a Pi-bus, TM-bus and 
IEEE-488 bus backplane. Data on the Pi-bus and TM-bus is linked to the simulation computer via 
the 1553 system bus interface. The IEEE-488 is used primarily for module software load and 
debug operations. 

TTAWG Common Modules - The common modules housed in the chassis are tested and 
monitored for fault information. As a minimum, the modules in the chassis will consist of a 
1750A processor, a 1553 bus interface, and a power supply. The 1750A processor module 
performs the primary processing required to support the demonstration. The 1553 bus interface 
module provides the interface to the system bus, which provides the communication link between 
the modules and demonstration controller. The power supply provides the power needed by the 
common module suite. 

VME Chassis - A 6U chassis with a VME backplane may be used as the simulation computer. In 
this capacity, its responsibility would be to coordinate the test demonstration and provide an 
interface between the common modules under test and the display computer. If a different 
computer system is chosen to be the simulation host, then the VME chassis may be required to 
serve as a interface between that computer and the common modules. 

PC Display Hardware - The display computer emulates a Ground System. If a PC is used to 
display the demonstration data, it will consist of a RS-232 digital I/O board and a PC compatible 
80386 type processor (as a minimum). 

SGI or SUN Display Hardware - If an SGI or Sun system is chosen as the display host, the 
display information will be transferred via Ethernet buses 

5.3.4 Demonstration Software 

Demonstration software will be developed to support the demonstration of the automated test 
concepts. Code for the processor modules will be developed using Ada and loaded via the IEEE- 
488 bus. Software hosted on the display computer and simulation computer will be written in C. 

JIAWG Common Modules - Each common module contains Applications Self-Test Software, 
Initiated Self-Test Software, and Maintenance Controller Firmware to support BIT operations. A 
calling program will be resident on the system bus interface module, which will serve as the on- 
board test coordinator. The purpose of the calling program is to interrogate the various fault logs 
and status registers on each of the modules in the cluster and report over the 1553 system bus to 
the Test Coordinator (simulation computer). 
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Display Computer - The display computer hosts a C language program with the function of 
receiving health status information over the System Test & Maintenance Network (Ethernet or RS- 
232) and displaying it in graphical form. 

Simulation Computer - This computer will host a C language program to perform the Test 
Coordinator function, interface the System Bus with the System Test & Maintenance Network, 
monitor the health of the System Bus, and translate BIT information to graphical form for the 
Display Computer. 

5.4 Demonstration Schedule & ROM Estimated Cost 

The es tima ted cost and schedule for the three year Avionics BIT program is shown, by year, in the 
lower right of the quad chart in Figure 8. The estimates are rough order of magnitude (ROM),and 
should be used for planning purposes only. The estimates for FY94, FY95, and FY96 are $200K, 
$400K, and $700K respectively, with the total program estimated to be $1.3M. 


The estimate is presented in inflation-adjusted. Real Year dollars, and reflects estimated contract 
labor only. This estimate assumes all hardware required for performance of this demonstration 
will be provided by either the contractor or the government at no cost to the contract. In addition, 
all deliverables are assumed to be tests and demonstrations, and data and reports, with no specified 
hardware or software deliverables. The program builds on each prior year s developments to 
accomplish additional items each year. Although not shown on the schedule, demonstrations 
would occur at the end of the first year and every six months following the first demonstration. 


6.0 Report Conclusions 

The potential benefits for VHM apply not only to today’s vehicles but tomorrow’s as well. 
Implementing the highest priority demonstration will help achieve the benefits in operations. The 
greatest benefits for VHM occur with the completion of all projects. However, confidence in the 
improvements in costs and reliability will be shown with this first program. 

The avionics BIT demonstration will begin the reduction of operations costs using automated 
VHM. The avionics system will be the foundation for adding VHM in propulsion, pneumatics and 
data analysis. The project should be completed within three years. The plan has been developed 
after considering many alternatives. Its implementation is strongly recommended. 
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